Users of physical or virtual machines commonly install software packages, including package updates, to physical or virtual machines. The software packages can contain a set of related files chosen to perform a given application or task, such as, for example, a group of software applications, drivers, and/or other resources used to install and use messaging or media applications. In instances, a software package can contain application software, operating system software, drivers, patches, and/or other software components grouped as a logical set. In implementations, the package can be stored or encoded as a single file or data object.
Software package update managers exist to help a user initiate and perform software package updates, such as, for example, the “yum” (Yellowdog update manager) package update manager available from Red Hat, Inc., Raleigh, N.C., and others. In general, available software package managers are configured to interact with the set of installed packages on a client and with one or more software package repositories, to directly connect to those databases and download available package updates.
The process of initiating software package updates can involve, however, the risk or possibility of software-related faults, instabilities, bugs, or other undesirable errors or conditions. A number of those potential faults or irregular conditions can have a tendency to occur during the window of time in which package updates are made. For example, a user who repeatedly downloads and installs updates for a variety of unrelated packages may incur the risk of overwriting copies of files with inconsistent or undesired versions of those files. Further, a user may choose to initiate a package update process without fully verifying or validating the source of the package update files, and retrieve and install those files without any virus scans, black-list check, or other security measures.
A user may also overlook an independent condition on the target machine or client that can cause a fault event during a package installation, and, therefore, be unable to discriminate between machine faults or crashes caused by the installation itself versus those that may be caused by separate application faults or other independent events. This can be especially true on machines that are executing a large number of applications or services at the time of the package update. Because existing package update managers are not configured to monitor machine state data before, during, and after a package installation, nor to differentiate between fault events induced by the package update event versus independent machine faults, those faults occurring around the time of package installation or update events can be difficult to debug, and may remain undiagnosed. It may be desirable to provide systems and methods for storing machine state history related to detected faults in the package update process, in which diagnostic logic and user notification can be integrated into the package update process to detect, diagnose, and correct potentially problematic updates and/or other system conditions associated with the package manager or the client, during or after the update activity takes place.